DEV Community: Lucas Maltempi Monfardine

Configuring ESLint for AWS-CDK on VSCode

Lucas Maltempi Monfardine — Tue, 23 Apr 2024 10:55:29 +0000

If you, like me, landed on AWS-CDK from the flying world of Terraform and has a good taste for well-indented files, one of the first things you will notice is that for working with TypeScript, keeping your files looking clean and beauty is not as simple as installing a single VSCode plugin.
Wanna change that? Follow along.

Assumptions

The guide below assumes that you have already:

VSCode installed
Node installed
NPM installed
A CDK TypeScript project bootstraped

Project dependencies

Install ESLint packages

npm install -D eslint-config-love

Then, run the init config for ESLint:

npx eslint --init

It will ask you a couple of questions (pay attention to the browser/node one, as this allows you to pick both), ask you to install some dependencies, which you can confirm and finally genereate a esling.config.mjs file.

The esling.config.mjs file can be adjusted later.

VSCode Extension

In VSCode Extensions marketplace, install the ESLint extension:

Customizing ESLint config

It takes some effort to put all the available settings of ESLint in place and get a decent result. You can check
eslint-config-love for detailed instructions on how to create settings that match your needs.

Or you can make use of the example below that has already some formatting standards setup and apply your changes as you identify them. Just save the content of this file into your esling.config.mjs and see what happens.

For this to work, install some aditiona NPM packages:

npm install -D @stylistic/eslint-plugin @typescript-eslint/eslint-plugin @typescript-eslint/parser eslint-plugin-import eslint-import-resolver-typescript

Important note: as my CDK code usually stays on "infrastrusture" folder, extra parameter tsconfigRootDir is necessary to tell linter where to find tsconfig.json file. Else, linter won't be able to find the imports.

import stylisticPlugin from '@stylistic/eslint-plugin';
import typescriptPlugin from '@typescript-eslint/eslint-plugin';
import typescriptParser from '@typescript-eslint/parser';
import importPlugin from 'eslint-plugin-import';
import globals from 'globals';

export default [
    {
        ignores: [
            '*.js',
            '!.projenrc.js',
            '*.d.ts',
            'node_modules/',
            '*.generated.ts',
            'coverage',
            '!.projenrc.ts',
            '!projenrc/**/*.ts',
        ],
    },
    {
        files: ['**/*.{js,ts}'],
        languageOptions: {
            parser: typescriptParser,
            parserOptions: {
                ecmaVersion: 2020,
                sourceType: 'module',
                project: './tsconfig.json',
            },
            globals: {
                ...globals.jest,
                ...globals.node,
            },
        },
        plugins: {
            '@typescript-eslint': typescriptPlugin,
            import: importPlugin,
            '@stylistic': stylisticPlugin,
        },
        settings: {
            'import/parsers': {
                '@typescript-eslint/parser': ['.ts', '.tsx'],
            },
            'import/resolver': {
                node: true,
                typescript: {
                    project: './tsconfig.json',
                    alwaysTryTypes: true,
                },
            },
        },
        rules: {
            indent: 'off',
            '@/indent': ['error', 2],
            quotes: ['error', 'single', { avoidEscape: true }],
            'comma-dangle': ['error', 'always-multiline'],
            'comma-spacing': ['error', { before: false, after: true }],
            'no-multi-spaces': ['error', { ignoreEOLComments: false }],
            'array-bracket-spacing': ['error', 'never'],
            'array-bracket-newline': ['error', 'consistent'],
            'object-curly-spacing': ['error', 'always'],
            'object-curly-newline': ['error', { multiline: true, consistent: true }],
            'object-property-newline': ['error', { allowAllPropertiesOnSameLine: true }],
            'keyword-spacing': ['error'],
            'brace-style': ['error', '1tbs', { allowSingleLine: true }],
            'space-before-blocks': ['error'],
            curly: ['error', 'multi-line', 'consistent'],
            '@stylistic/member-delimiter-style': ['error'],
            semi: ['error', 'always'],
            'max-len': [
                'error',
                {
                    code: 150,
                    ignoreUrls: true,
                    ignoreStrings: true,
                    ignoreTemplateLiterals: true,
                    ignoreComments: true,
                    ignoreRegExpLiterals: true,
                },
            ],
            'quote-props': ['error', 'consistent-as-needed'],
            '@typescript-eslint/no-require-imports': ['error'],
            'import/no-extraneous-dependencies': [
                'error',
                {
                    devDependencies: true,
                    optionalDependencies: false,
                    peerDependencies: true,
                },
            ],
            'import/no-unresolved': ['error'],
            'import/order': [
                'warn',
                {
                    groups: ['builtin', 'external'],
                    alphabetize: {
                        order: 'asc',
                        caseInsensitive: true,
                    },
                },
            ],
            'no-duplicate-imports': ['error'],
            'no-shadow': 'off',
            '@typescript-eslint/no-shadow': ['error'],
            'key-spacing': ['error'],
            'no-multiple-empty-lines': ['error'],
            '@typescript-eslint/no-floating-promises': ['error'],
            'no-return-await': 'off',
            '@typescript-eslint/return-await': ['error'],
            'no-trailing-spaces': ['error'],
            'dot-notation': ['error'],
            'no-bitwise': ['error'],
            '@typescript-eslint/member-ordering': [
                'error',
                {
                    default: [
                        'public-static-field',
                        'public-static-method',
                        'protected-static-field',
                        'protected-static-method',
                        'private-static-field',
                        'private-static-method',
                        'field',
                        'constructor',
                        'method',
                    ],
                },
            ],
        },
    },
    {
        files: ['.projenrc.js'],
        rules: {
            '@typescript-eslint/no-require-imports': 'off',
            'import/no-extraneous-dependencies': 'off',
        },
    },
];

Running the linter

Include a script to run eslint in yourpackage.json file:

"eslint": "npx eslint --ignore-pattern .ts,.tsx --fix --no-error-on-unmatched-pattern lib bin test"

After that, you can run npm run eslint for a list of files that don't match the pattern you defined. Happy coding.

Encrypting your secrets with Mozilla SOPS using two AWS KMS Keys

Lucas Maltempi Monfardine — Tue, 16 Jan 2024 22:30:19 +0000

This article can also be found on my GitHub, along with Terraform code.

TL;DR

Just set two distinct KMS Keys ARN, comma separated, into the variable SOPS_KMS_ARN prior to using SOPS.

export SOPS_KMS_ARN="arn:aws:kms:us-east-1:656532927350:key/920aff2e-c5f1-4040-943a-047fa387b27e,arn:aws:kms:ap-southeast-1:656532927350:key/9006a8aa-0fa6-4c14-930e-a2dfb916de1d"

Introduction

Sometimes pushing files to Git would be much easier than storing them in complex encryption management systems, but everyone knows it's not safe to push API Keys, passwords and private keys as plain text (neither base64) to Git, right?
To help on that mission, a very useful tool we can count on is Mozilla SOPS (read more below). And when you are working with multiple cloud accounts (like landing zone on AWS), or in different regions, you can include a extra layer of security by encrypting secrets with two distinct KMS keys. This way, if you ever lose access to one of your KMS keys, you will still be able to retrieve your secrets.

Mozilla SOPS

Mozilla SOPS (Secrets OPerationS) is an open-source command-line tool for managing and storing secrets. It uses secure encryption methods to encrypt secrets at rest and decrypt them at runtime. SOPS supports a variety of key management systems, including AWS KMS, GCP KMS, Azure Key Vault, and PGP. It's particularly useful in a DevOps context where sensitive data like API keys, passwords, or certificates need to be securely managed and seamlessly integrated into application workflows.

Setting things up

This example uses Terraform to configure AWS KMS Keys with a policy that permits them to be accessible by other AWS accounts. The same can be done with CloudFormation, directly on AWS Console or even AWS CLI.

Starting by the "root" account, the one that will store our "emergency" key, we gonna need:

A KMS Key dedicated to SOPS

resource "aws_kms_key" "sops" {
  description             = "SOPS encryption KMS Key"
  deletion_window_in_days = 10

}

resource "aws_kms_alias" "sops" {
  name          = "alias/sops-key"
  target_key_id = aws_kms_key.sops.key_id
}

And a policy that allows this key to be used by other accounts

resource "aws_kms_key_policy" "sops_kms_policy" {
  key_id = aws_kms_key.sops.id
  policy = jsonencode({
    Id = "sops-kms-foreign-accounts"
    Statement = [
      {
        Action = "kms:*"
        Effect = "Allow"
        Principal = {
          AWS = local.principals
        }

        Resource = "*"
        Sid      = "Enable other accounts IAM Users to use this key"
      },
    ]
    Version = "2012-10-17"
  })
}

With the use of locals, we can concatenate multiple accounts, so if you have a Platform team managing accounts for your company, new accounts can be easily included there.

locals {
  principals = concat(["arn:aws:iam::${var.accountID}:root"], [for id in var.kms_principals_acc_ids : "arn:aws:iam::${id}:root"])
}

Now we need a KMS Key in our main account, that don't need to be shared for this use case, and the standard code will work

resource "aws_kms_key" "sops" {
  description             = "SOPS encryption KMS Key"
  deletion_window_in_days = 10

}

resource "aws_kms_alias" "sops" {
  name          = "alias/sops-key"
  target_key_id = aws_kms_key.sops.key_id
}

Usage

Now that we have both keys created, getting their ARNs is the next step. In this approach, our KMS keys ARN have the same alias, being the account ID the only value that will change between them. So, assuming our Account A has the ID 123456789012 and our account B has the ID 012345678901, our matching Keys would be:

Account A: arn:aws:kms:eu-west-1:123456789012:alias/sops-key
Account B: arn:aws:kms:eu-west-1:012345678901:alias/sops-key

Next step is export both ARNs, comma-separated, as value of SOPS_KMS_ARN variable.

export SOPS_KMS_ARN=arn:aws:kms:eu-west-1:123456789012:alias/sops-key,arn:aws:kms:eu-west-1:012345678901:alias/sops-key

Last, just run SOPS, specifying the file you want to create or edit. SOPS supports YAML and JSON, and will always encrypt the values, but not the keys in your file.
The following command creates a new file:

sops example.yaml.enc

And then we can store our values.

data:
  - some
  - array
  - elements

After closing the editor, our file will look something like this:

data:
    - ENC[AES256_GCM,data:v8jQ=,iv:HBE=,aad:21c=,tag:gA==]
    - ENC[AES256_GCM,data:X10=,iv:o8=,aad:CQ=,tag:Hw==]
    - ENC[AES256_GCM,data:KN=,iv:160=,aad:fI4=,tag:tNw==]
sops:
    kms:
        - created_at: 1441570389.775376
          enc: CiC....Pm1Hm
          arn: arn:aws:kms:eu-west-1:123456789012:alias/sops-key
        - created_at: 1441570391.925734
          enc: Ci...awNx
          arn: arn:aws:kms:eu-west-1:012345678901:alias/sops-key

And it will be ready to be pushed to your Git repository, with no risk to the integrity of the data.

Hint: for fast decryption, you can use -d parameter and get the file contents printed into the console, or redirected to another file.

sops -d example.yaml.enc > example.yaml

Protecting Terraform variables

Assuming we could have sensitive values in our Terraform variables, we can make use of SOPS to protect these variables, making them readable locally or in a pipeline only for users with access to our KMS Keys. To do that the first step is to convert our variables file from HCL to JSON, which is a file format supported by both Terraform and SOPS.

Once the values are stored as JSON, the procedure is the same as above.

sops variables/production.tfvars.json.enc

With the decripted values, Terraform will accept them as input, just like the HCL:

sops -d variables/production.tfvars.json.enc > variables/production.tfvars.json

terraform plan -var-file=variables/production.tfvars.json -out tfplan

Tips

Use VSCode as editor

SOPS supports many text editors to manipulate your secrets. If you are a lover of VSCode, the following command will bring it up as editor for the SOPS file you want to edit:

EDITOR="code --wait" sops variables/production.tfvars.json.enc

Dynamic accounts

In my use cases, my Account A always tends to be static, but the ID for Account B usually changes. The code below can help getting the right account ID, along with the static one, in such case. The only requirements are AWS CLI, previous AWS authentication and the jq tool.

export SOPS_KMS_ARN="arn:aws:kms:eu-west-1:$(aws sts get-caller-identity --output json | jq '.Account' -r):alias/sops-key,arn:aws:kms:eu-west-1:123456789012:alias/sops-key"

hcl2json

If you have a big HCL file that you want to convert to JSON, hcl2json may be the perfect tool to help you on that task.

Redundant Site-to-Site IPSecVPN between AWS and pfSense

Lucas Maltempi Monfardine — Thu, 11 Jan 2024 21:09:38 +0000

Disclaimer: this article was published originally on Medium, in December 2021 and may not be 100% up to date.

While setting up a IPSec tunnel between an AWS VPC and a pfSense gateway is simple at first look, there’s a little trick to make it work with both tunnels provided by AWS active at same time, working with VTI tunnels.

Here’s a simple guide, if you ever need to connect your local network to a AWS VPC.

Part 1: Amazon side

First, let’s set things up on Amazon side. Go to VPC menu, then to Customer Gateways and Create Customer Gateway

On the new Customer Gateway screen, set a name for your gateway, choose Static Routing and insert your static public IP address (the one that will be used as gateway on your IPSec tunnel). Then, create the Customer Gateway.

You can check the State to make sure it’s available.

Now, got to Virtual Private Gateways menu and create a new Virtual Private Gateway.

Name tag field is optional, and for ASN, pick Amazon Default ASN.

The Virtual Private Gateway will be created on a detached state.

Then, select the Virtual Private Gateway you just created, go to the Actions menu and select Attach to VPC.

On the next screen, select the VPC you want to connect with your local network and click on Yes, Attach.

After a while, it will change the state from attaching to attached.

Then, move to Site-to-Site VPN Connections and Create VPN Connection.

For the new VPN Connection, choose a name and pick the previously created Virtual Private Gateway and Customer Gateway. On Static IP Prefixes insert each network on your local side that will need to be accessed by AWS resources.

Leave all the other options as default and then create the VPN Connection.

On the next screen it will appear as pending, and after a while, will change to available.

Select the connection, go to Tunne Details, save the network CIDRs in there, that will be used later.

Go to Static Routes tab and check if your local network is there.

At the top of the screen, click into Download Configuration button, choose pfSense and save the provided TXT that will be used on the next steps.

Still into AWS Console, go to Route Tables and find the Route Table in use by your VPC.

After selecting the proper Route Table, go to Route Propagation tab and click Edit route propagation. Check the Propagate box and save.

Validate if the Propagate field changed to Yes on the previous screen.

Steps on Amazon are completed.

Part 2: pfSense side

Go to VPN > IPSec > Add P1 as you would normally do.

Use the instructions provided on the downloaded file to fill the P1 tunnel settings.

Save the settings matching what was provided and then Apply Changes on pfSense. P1 tunnels won’t be triggered until a P2 tunnel is set up.

To the next step, add a P2 tunnel:

Now, the trick:

Instead of picking Tunnel IPv4, set mode as Routed (VTI). Now we gonna use the Tunnel IPs provided on the AWS console.

Since each block is a /30, IPs are distributed as follows:

First IP: 169.254.43.192 — Network

Second IP: 169.254.43.193 — Is used on AWS side

Third IP: 169.254.43.194 — The one that should be used on pfSense

Fourth IP: 169.254.43.195 — Broadcast

Other settings are default as provided by AWS on the TXT file

To keep the tunnel UP, set ping to the AWS side IP

Repeat the same process for the second tunnel.

Now, go to Interfaces > Assignments

There you’ll have two new virtual network ports that you must add as interface

They will be created as new OPT interfaces, and must be renamed and enabled. It’s also a good idea to rename them to something related to the tunnel they belong to.

https://miro.medium.com/v2/resize:fit:640/format:webp/1*I8SxP2H6FCdsHcfSoYotrQ.png

After a while both tunnels will be up. You can validate that on AWS console.

For the last step, it’s important to set the routes on pfSense, so it will know how to reach private IPs on the other side of the tunnel. For that, go to System > Routing

Another important trick: to set routing, if your VPC has a CIRD /16 for example, one of the gateways will have the destination network matching the VPC IP and CIRD, and the second one will have two networks /17.

This way, the traffic will flow only through tunnel A. However, if it fails, it will be automatically routed through tunnel B.

Don’t forget to create a firewall rule on IPSec if you don’t have it already

And also don’t forget to set a security group to allow incoming connections to your AWS instances from your local network IPs.

OKD4 integration with Active Directory

Lucas Maltempi Monfardine — Wed, 10 Jan 2024 21:57:10 +0000

Disclaimer: this article was published originally on Medium, in March 2021 and may not be 100% up to date.

Quick guide on integrating a OKD4 cluster to login with Active Directory

Before going to OKD, it’s better gather the following information:

A dedicated AD service account (for binding purposes) with complete DN;
Domain name or AD IP;
Complete DN of a “control group” with users allowed to log in;
Complete DN of groups you want to sync.

Now to OKD: start by creating a secret for your LDAP Service Account password:

oc create secret generic ldap-secret --from-literal=bindPassword=<LDAP SA password> -n openshift-config

Next, let’s update the cluster authentication methods. This YAML will change existing OAuth cluster settings existing on openshift-config namespace:

apiVersion: config.openshift.io/v1  
kind: OAuth  
metadata:  
  name: cluster  
  namespace: openshift-config  
spec:  
  identityProviders:  
  - name: ldapidp  
    mappingMethod: claim  
    type: LDAP  
    ldap:  
      attributes:  
        id:  
        - sAMAccountName  
        email:  
        - mail  
        name:  
        - displayName  
        preferredUsername:  
        - cn  
      bindDN: "CN=OKD,OU=ServiceAccounts,OU=Users,DC=domain,DC=com"  
      bindPassword:  
        name: ldap-secret  
      insecure: true  
      url: "ldap://<ip-or-ad-domain>:389/OU=Users,DC=domain,DC=com?sAMAccountName?sub?(memberof=CN=okd-users,OU=groups,DC=domain,DC=com)"

Fields to change:

bindDN: replace with your LDAP Service Account complete DN
URL: replace with your server and the OU where your users are located on LDAP server.
The last part of the URL sets that only members of the group “okd-users” will be able to log-in. You can remove that if you want.

Then apply the file you generated:

oc apply -f path/to/ldap-auth.yaml

After applying, wait for the redeploy of authentication pods and you should be able to log in using your LDAP account.

Group Sync

For the group sync, there’s two needed files: ldap-group-sync.yaml and whitelist.txt

kind: LDAPSyncConfig  
apiVersion: v1  
url: ldap://<ip-or-ad-domain>:389  
insecure: true  
bindDN: CN=OKD,OU=ServiceAccounts,OU=Users,DC=domain,DC=com  
bindPassword: '<AD Service Account Password>'  
groupUIDNameMapping:  
  "CN=okd-admins,OU=Groups,DC=domain,DC=com": okd-admins  
  "CN=okd-project1-users,OU=Groups,DC=domain,DC=com": okd-project1-users  
augmentedActiveDirectory:  
    groupsQuery:  
        derefAliases: never  
        pageSize: 0  
    groupUIDAttribute: dn  
    groupNameAttributes: \[ cn \]  
    usersQuery:  
        baseDN: "OU=Users,DC=domain,DC=com"  
        scope: sub  
        derefAliases: never  
        filter: (objectclass=person)  
        pageSize: 0  
    userNameAttributes: \[ cn \]  
    groupMembershipAttributes: \[ "memberOf:1.2.840.113556.1.4.1941:" \]

Fields to change:

URL: replace with your AD server IP or domain
bindDN: replace with previously created service account
bindPassword: the service account password
groupUIDNameMapping: insert as many groups as you need
baseDN: replace with baseDN of your AD users

On the whitelist.txt file, insert the previously mentioned groups, one per line:

CN=okd-admins,OU=Groups,DC=domain,DC=com  
CN=okd-project1-users,OU=Groups,DC=domain,DC=com

After finishing the files edit, do a dry run to validade:

oc adm groups sync --whitelist=whitelist.txt --sync-config=ldap-group-sync.yam

If everything goes well, add the “confirm” flag to process the changes:

oc adm groups sync --whitelist=whitelist.txt --sync-config=ldap-group-sync.yaml --confirm

Check if your groups appeared on the console and then add the needed RoleBindings to them, accordingly:

Binding cluster-admin role to okd-admins group.

Group Sync automation

You could sync your groups manually whenever you need, or maybe schedule a cron in any host to do that. But there’s a cooler way. Let’s schedule a cronJob inside OKD cluster to constantly check for changes on your groups.

Start by creating a project “ldap-sync” and a Cluster Role that will give the propper permissions for the job to complete the task:

Create a file rbac-ldap-group-sync.yaml:

apiVersion: rbac.authorization.k8s.io/v1  
kind: ClusterRole  
metadata:  
  name: ldap-group-sync  
rules:  
\- apiGroups:  
  - user.openshift.io  
  resources:  
  - groups  
  verbs:  
  - create  
  - update  
  - patch  
  - delete  
  - get  
  - list

Then run:

oc apply rbac-ldap-group-sync.yaml

Next, create the cronjob-ldap-group-sync.yaml:

apiVersion: batch/v1beta1  
kind: CronJob  
metadata:  
  name: ldap-group-sync  
  namespace: ldap-sync  
spec:  
  schedule: '[@hourly](http://twitter.com/hourly)'  
  suspend: false  
  jobTemplate:  
    spec:  
      template:  
    spec:  
      template:  
        metadata:  
          creationTimestamp: null  
        spec:  
          restartPolicy: Never  
          serviceAccountName: ldap-sync  
          schedulerName: default-scheduler  
          terminationGracePeriodSeconds: 30  
          securityContext: {}  
          containers:  
            - name: oc-cli  
              image: registry.redhat.io/openshift4/ose-cli  
              command:  
                - /bin/oc  
                - adm  
                - groups  
                - sync  
                - '--whitelist=/ldap-sync/whitelist.txt'  
                - '--sync-config=/ldap-sync/ldap\_group\_sync.yaml'  
                - '--confirm'  
              volumeMounts:  
                - name: config  
                  readOnly: true  
                  mountPath: /ldap-sync/  
          serviceAccount: ldap-sync  
          volumes:  
            - name: config  
              secret:  
                secretName: ldap-sync  
                defaultMode: 420  
          dnsPolicy: ClusterFirst

And then create the task:

oc apply -f cronjob-ldap-group-sync.yaml

On OKD console you can see the history of events generated by the job.

Tips:

You can change the schedule from ‘@hourly’ to any valid Linux cron expression.
If you receive any errors on runnin the cron job, check if the serviceAccount line is present on the Cron Job in the OKD UI.

Bamboo: the worst CI/CD tool I ever had the "pleasure" to work with.

Lucas Maltempi Monfardine — Thu, 28 Dec 2023 13:31:15 +0000

Being I a very experienced professional in automation area, with many years of knowledge in a vast majority of marketing leader CI/CD Tools, like Gitlab-CI (ok, Gitlab-CI, mostly), I've recently got challenged to build some pipelines using this fantastic Atlassian tool: Bamboo.
Why? Because that's what the company uses and pays for, and it's the one I'm allowed to use.
Below I'll present a few things that I've discovered regarding this ~~schizophrenic~~ wonderful tool.

GUI Editor

If you are a experienced DevOps, there's probably a feature you like a lot and miss in all those simple, lightweight, cool CLI tools. That's it: a Graphical User Interface. Well, fear no more. Atlassian has put a lot of effort into building a very fast, practical and beautiful way to graphically edit your pipelines directly on Bamboo web interface. This way you can configure your pipeline just by click-click-click, drag, and always be unsure if the outcome will be as expected.
The only good thing on that is: you can export your pipeline to YAML (or Java) after it's done.

Encrypted Secrets

If you are creating your pipeline directly in the UI, you can just paste sensitive data in the Variables menu rows, and if Bamboo thinks the data is sensitive, based in the name of the variable (it MUST contain "password", "passphrase", "secret" or "sshkey" in the name) it will automatically convert the value to a encrypted secret for you.

Now, if you are coding your pipeline (YAML, Java), what would be better than using the same variables menu and just inject the values in the runtime? Exactly: Put encoded values in your YAML.
Bamboo has a very unique system for secrets encryption, where you insert your original value and it will be converted to some hashed value that looks like a standard text concatenated to some base64. Don't fool yourself, the value is encrypted with a key unique to your server, and won't work in any other instance of Bamboo.

Ok, now I can get this value and use anywhere I want on my YAML, right?

Yeah, kinda. But you MUST follow the same rules applied to the UI. That means, if you define your variable like this, it will never be decrypted/usable.

Now, if you just include secret in the name of the variable, you can see the magic happen in your pipeline.

Fantastic, isn't it?

Cache

Not much to write about this topic. If yo are building a CI pipeline, you want it to be as fast as it can. How can you save a lot of time from downloading dependencies everytime you run a build? Cache.
So, what about cache in Bamboo? It DOES-NOT-EXIST. Simply like that, nothing else to say.

Permission granularity

This may be a good feature, depending on the way you look. But listen:

You have a project inside Bamboo. You gotta include users (or groups) and grant them permissions there.
Then you have repositories, which are linked to your Git. And you gotta set permission to who can see the repositories you included in your project. And you have to also specify which users and groups can see each of the repositories you have included, despite having previously set permissions at project level.
Now you get your project, and your repository, and you want to configure a plan. Guess what? Exactly. You have to set the same permissions again. Why? Well, somebody thought it was a good idea.