avatarPaddy Corry

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

5791

Abstract

7156">I covered user-specific secrets here:</p><div id="744d" class="link-block"> <a href="https://readmedium.com/create-a-per-user-secret-in-secrets-manager-part-1-bb97b66e2a2d"> <div> <div> <h2>User-Specific Secrets on AWS: IAM Policies</h2> <div><h3>ACM.82 IAM Policies to allow users to describe their own secrets</h3></div> <div><p>medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/1*PcniDpBJq2db0jbdryc_Nw.png)"></div> </div> </div> </a> </div><h2 id="aada">Create the user-specific Secret to store the automation credentials</h2><p id="a515">Next I create <b>SandboxDevAutomationSecret</b> in Secrets Manager, encrypted with my <b>Sandbox KMS key</b>.</p><figure id="e15e"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*DQonCyF8UzPnZZoiGOKD9w.png"><figcaption></figcaption></figure><figure id="f7b3"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*zITxEtD__wFDwpPrBpqv4w.png"><figcaption></figcaption></figure><h2 id="2e63">Create a user-specific EC2 instance role for the SandboxDev user</h2><p id="3417">Next I create an EC2 instance role that the developer is allowed to pass to EC2 instances named <b>SandboxDevEC2Role</b>.</p><figure id="44ef"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*__fohZeTWjwdYrS__B4imQ.png"><figcaption></figcaption></figure><p id="eee9">The role will have a prefix with the username:</p><figure id="7afa"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*7dKW5KiQMivtKqjgzA_1Gw.png"><figcaption></figcaption></figure><p id="a338">This role is granted access to:</p><ul><li>Read the<b> SandboxDevSecret.</b></li><li>Pull containers from the <b>sandbox Elastic Container Repository.</b></li><li>Use the <b>sandbox KMS key </b>to access decrypt the secret and the container in the repository</li></ul><h2 id="df90">Create the Automation user</h2><p id="b752">Create the <b>SandboxDevAutomation</b> user. Do not give this user console access.</p><figure id="ddeb"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*QWVvQMA9aDCtmiVxSR61iw.png"><figcaption></figcaption></figure><p id="c19e">Remember that I already have a role (<b>CloneGitHubtoCodeCommitRole</b>) used by my batch job from prior posts. Create a policy that allows the SandboxDevAutomation user to use STS to assume that role.</p><p id="559f">The <b>SandboxDev</b> user needs permission to change the <b>credentials</b> <b>and</b> MFA device of the <b>SandboxDevAutomation</b> user.</p><h2 id="0f53">Edit the batch job role trust policy to allow the SandboxDevAutomation role to assume it</h2><p id="7f1d">We need to modify the trust policy to allow the <b>SandboxDevAutomation</b> <b>user</b> to assume the <b>CloneGitHubtoCodeCommitRole</b> role with MFA.</p><figure id="6ad1"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*xAHGslW3SSbv6c5NO8mhzg.png"><figcaption></figcaption></figure><p id="7ad0">Edit the trust policy:</p><figure id="cfaf"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*Vna71G_F2e-8Vdtw4yBwFw.png"><figcaption></figcaption></figure><p id="6a5a">Change the user to SandboxDev:</p><figure id="f788"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*vpSqEqjFa_qg59v_dnPCzQ.png"><figcaption></figcaption></figure><h2 id="49b3">Add permissions to KMS Key Resource Policy</h2><p id="8cf1">Next I need to allow the <b>SandboxDev</b> user to encrypt and decrypt and the <b>SanboxDevEC2Role</b> to decrypt with the <b>sandbox KMS Key.</b> I edit my automation to add those two roles to the encrypt and decrypt users.</p><figure id="380f"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*UkzCt10p0iqCR4OpMs6uhQ.png"><figcaption></figcaption></figure><h2 id="d015">Login as SandboxDev</h2><p id="725d">Log into the AWS Console with the SandboxDev user. If you’ve been following along, you have an account with a prefix specific to your organization and -Dev at the end if you used my deployment scripts.</p><figure id="13d5"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*5L-3C9ORVXOWv6KRdCkBLg.png"><figcaption></figcaption></figure><h2 id="d260">Add MFA devices</h2><p id="5cca">Add a Hardware MFA device to the SandboxDev User.</p><figure id="21f0"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*8s8rTuyWOsLAQUEqfwTtOQ.png"><figcaption></figcaption></figure><p id="c0e6">Add a Virtual MFA device to the SandboxDevAutomation User.</p><p id="5cec">I explain why I do not use a Yubikey to generate MFA codes here:</p><div id="1308" class="link-block"> <a href="https://readmedium.com/the-yubikey-cli-and-aws-mfa-50e6be0698a7"> <div> <div> <h2>The Yubikey CLI and AWS MFA</h2> <div><h3>ACM.11 Considering the attack surface and MFA choices for our Security Batch Jobs</h3></div> <div><p>medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/1*SFAKbcK__GlbJbJJJVXK9w.png)"></div> </div> </div> </a> </div><figure id="5893"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*iFl4DTQNuplt-SGONHpNYw.png"><figcaption></figcaption></figure><h2 id="d7df">Create automation credentials</h2><p id="b9e4">Create an <b>Access key</b> for the <b>SandboxDevAutomation</b> user.</p><figure id="7f1e"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*KoVfxp-aJvzBiacPyFeMlA.png"><figcaption></figcap

Options

tion></figure><p id="217e">I have explained before that I disagree with the verbiage on this page. The CLI in the browser has a much larger attack surface and it depends how you are using the keys.</p><figure id="0423"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*_CCe4xu8AcNLloUHgvF5Aw.png"><figcaption></figcaption></figure><h2 id="8caa">Store the credentials in the SandboxDevAutomationSecret</h2><p id="24aa">Head to the Secrets Manager dashboard.</p><p id="432d">Click on the SandboxDevAutomationSecret.</p><figure id="6893"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*cz9jnYSnBsGXf9Y8VZjGPQ.png"><figcaption></figcaption></figure><p id="f616">Store the secret key id and secret access key.</p><figure id="4b95"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*-G9eR929nKSsGWrsOuzucg.png"><figcaption></figcaption></figure><h2 id="5496">Test Launching an EC2 Instance with the SandboxDev role</h2><p id="8907">Head over the EC2 dashboard and test launching an EC2 Instance. Recall that the Instance name needs to match what we specified in the policy above.</p><figure id="a1c7"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*FqCLLp7V854JJZa88TIdvA.png"><figcaption></figcaption></figure><p id="2bc8">If you need to decode any error messages I explained how to do that here:</p><div id="bb13" class="link-block"> <a href="https://readmedium.com/decoding-aws-error-messages-db0e0cbecf0d"> <div> <div> <h2>Decoding AWS Error Messages</h2> <div><h3>Free Content on Jobs in Cybersecurity | Sign up for the Email List</h3></div> <div><p>medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/1*4oxP4LXk8l8c3mpRvO7ejg.png)"></div> </div> </div> </a> </div><p id="bd85">Choose the existing networking created for EC2 instances from prior posts.</p><div id="a149" class="link-block"> <a href="https://readmedium.com/automating-cybersecurity-metrics-890dfabb6198"> <div> <div> <h2>Automating Cybersecurity Metrics (ACM)</h2> <div><h3>A series of blog posts on cybersecurity metrics and security automation</h3></div> <div><p>medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/1*L9lEIsaWt6xm2Op2ww-G5w.png)"></div> </div> </div> </a> </div><p id="2937">Choose the role we created under Advanced details.</p><figure id="8870"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*oHJior3Ueea6woDB1zqqKQ.png"><figcaption></figcaption></figure><p id="a822">One note that took me a bit to resolve. The message when your user does not have permission to pass the IAM role to the EC2 instance is a bit ambiguous.</p><div id="a0fb" class="link-block"> <a href="https://readmedium.com/ambiguous-error-message-when-a-user-doesnt-have-permission-to-pass-a-specific-iam-role-to-an-ec2-b005f338b6df"> <div> <div> <h2>Ambiguous Error Message When a User Doesn’t Have Permission to Pass a Specific IAM Role to an EC2…</h2> <div><h3>This error message needs to be more specific and doesn’t show up in CloudTrail for the User Name</h3></div> <div><p>medium.com</p></div> </div> <div> <div style="background-image: url(https://miro.readmedium.com/v2/resize:fit:320/1*4oxP4LXk8l8c3mpRvO7ejg.png)"></div> </div> </div> </a> </div><p id="51b2">Getting the resources setup took some time because I realized I had to revise my approach. I didn’t automate any of this but I will in the future. For now I just want to make sure it works. I can also figure out what permissions each policy requires.</p><p id="1fb5">I will test the initialization script in the next post.</p><p id="2c31">Follow for updates.</p><p id="4a3a">Teri Radichel | <i>© <a href="https://2ndsightlab.com/?source=post_page---------------------------">2nd Sight Lab</a> 2023</i></p><div id="8b5f"><pre><span class="hljs-section">About Teri Radichel:

⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab</pre></div><div id="caae"><pre><span class="hljs-section">Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</span>
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation</pre></div><div id="530b"><pre>Follow <span class="hljs-keyword">for</span> more stories like <span class="hljs-keyword">this</span>:

❤️ Sign Up my Medium Email List ❤️ Twitter: <span class="hljs-meta">@teriradichel</span> ❤️ LinkedIn: https:<span class="hljs-comment">//www.linkedin.com/in/teriradichel</span> ❤️ Mastodon: <span class="hljs-meta">@teriradichel</span><span class="hljs-meta">@infosec</span>.exchange ❤️ Facebook: 2nd Sight Lab ❤️ YouTube: @2ndsightlab</pre></div><figure id="eecf"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*H9Ew1KCl-29nZiPR.jpeg"><figcaption></figcaption></figure></article></body>

Courage exists in many forms

Living the Scrum Values — Episode 2

Courage exists in many forms, and can be difficult to recognise. This purpose of this post is to highlight some of those forms of courage, because if we see them, we can encourage them in our teams and organisations. The English language is oddly apt sometimes… Let’s encourage our teams in these 7 ways.

Prologue — Can you put it in context?

In the cult British TV Comedy ‘The IT Crowd’, there’s a wonderful episode where the inscrutable Moss is participating in a TV Gameshow named Countdown.

Countdown is an enigmatically English show where participants play games with letters and numbers. When asked to form a word from nine available letters, Moss proposes a nine-letter word ‘tnetennba’. “Goodness me”, exclaims Jeff, the host, “could you use it in a sentence for us?”

“Good morning”, Moss replies, “that’s a nice tnetennba.”

When it comes to courage, the Scrum Guide leaves things similarly open and without context. Here is the entirety of the text in the SG related to courage:

“The Scrum Team members have courage to do the right thing and work on tough problems.” — SG

That’s a nice tnetennba, isn’t it!? I‘ve written in the past about how scrum is an abstract class, obliging teams to provide the implementation. Well, when it comes to explaining courage, the Scrum Guide sure is abstract! Let’s break it down a little bit.

Values exist through behaviours

Ed Schein’s definition of culture shows espoused values as an inner layer of culture. They are manifested in the behaviours and artifacts of the team. However, behaviours can vary wildly in different contexts. This means also that values will not be manifested in exactly the same way in any two different settings.

In this post, I’m describing 7 behaviours that can demonstrate courage. It’s by no means a prescriptive list, and in fact, I’d love to supplement it with others. I’d really love to know if you have any to add! Ok, let’s begin.

1. Courage to do the right thing

Let’s start with the most obvious behaviour suggested by the Scrum Guide: doing the right thing. For me, there is an obvious behaviour to demonstrate this, and it is the ability to reduce the backlog of the team to the most valuable work. Some might describe it as the ability to say no to stakeholders. Others might refer to the simplicity principle in the agile manifesto. Words to live by.

“Simplicity — The Art of Maximising the Work Not Done” — Agile Manifesto

Gunther Verheyen believes that “we show courage in not building stuff that nobody wants.” (Source: GutherVerheyen.com) and I would tend to agree.

(Source: Jeff Sutherland’s Presentation to Scrum Gathering, Minneapolis ‘18)

Jeff Sutherland also agrees, and believes that, in general, teams spend 45% of their time building features that customers will never use, and a further 30% of their time on dark work, death marches or aimless work with only a distant relationship to any definition of customer value.

Just let that sit for a moment. 75% of the work done by many teams has almost zero value. We should have the courage to recognise this and say no to it.

In the excellent Agile Product Ownership in a Nutshell, Henrik Kniberg calls ‘no’ “the most important word for a product owner”. These are strong voices weighing in in favour of courageously saying no to those asking for this work.

Here’s the thing though, as any product owner will tell you, saying no ain’t easy! We all need to keep our jobs, and saying no to important stakeholders can be severely career-limiting. We need practical help getting to ‘no’.

Perhaps a better target would be to prevent more of this so called ‘dark work’ from reaching the development teams, and working with stakeholders in a product discovery mindset. This kind of mindset can encourage collaboration with our customers, and can examine prospective product ideas in a repeatable, falsifiable way that everyone understands. In this way, ideas can be funnelled before any user stories are written or refined, or before any code is written.

Download the A3 PDF here: JPattonAssociates.com

Jeff Patton’s Opportunity Canvas is an excellent example of a way to do this. Please follow Jeff’s pragmatic advice:

1. Most ideas are crap.

2. We are biased to believe that our ideas are better than everybody else’s.

3. Even if we acknowledge point number 1 as true, we are also biased to believe that everybody else’s ideas are crap, not ours.

This canvas provides a great way to work with stakeholders to evaluate ideas in a more objective way, without those pesky biases clouding our judgement.

Take Jeff’s template and adapt it for your organisation. You’ll be better able to get to no when you need to. It will take courage to use the opportunity canvas, but the outcome will be better and less career-limiting than a flat ‘no’.

2. Courage to Experiment (and to fail!)

Jeff Sutherland also referred to courage in the Scrum at Scale Guide, and this description is a little less abstract than the SG:

“Courage refers to taking the bold leaps required to deliver value quicker in innovative ways.” — SASG

This is a reference to experimentation for me. In order to ‘uncover better ways’ of doing things, as the agile manifesto suggests, we need to create an environment where experimentation and failure are permitted. This requires openness from a team, and it also requires courage.

Openness supports transparency, so that inspection and adaptation can also happen. However, when we are experimenting with new ways of doing things, we need the courage to speak up and suggest these ideas in the first instance. In addition, we need to know that it is safe to experiment. If this idea fails, will individuals lose face, or will our team try to learn together from the failure?

I discussed psychological safety and openness in an earlier post in this series, so I won’t repeat those ideas too much here, but openness is related to feelings of safety in a team setting. To encourage experimentation, we should emphasise the value of psychological safety in teams. Google certainly does.

In relation to the ability to speak up in a team setting, Amy C. Edmondson, Novartis Professor of Management and Leadership at Harvard Business School believes that “when people are willing to speak up, it’s usually because considerable effort has been put into creating a culture of candor, learning, and innovation that facilities the open sharing of ideas, questions, and concerns” (Source: Stephanie Vozza, FastCompany.com)

The onus is on leaders in team situations to create that environment of candor and learning, and there are behaviours that can support those. Hey, guess what though, those behaviours also require courage!

3. Courage to be open to new learning opportunities.

There is a wonderful website related to our biases and how we get in the way of our own learning, called You Are Not So Smart. Effectively, we would all do well to remember that if we limit a team to our own knowledge, and declare ourselves closed to opportunities to learn new things, then team members will never be able to show what they know.

As John Clopton recently explained here at Serious Scrum, it is easy to limit the progress a team if you believe your knowledge trumps theirs.

The autocratic style of leadership should not be the default in a team of experts, where craftsmanship is required. Imagine running a ‘think tank’ where lawyers or doctors are the team members, and you are the manager. If you run the team in an autocratic style, by giving orders and telling them what to do, not only would you look like a fool, you would miss out on a wonderful learning opportunity.

Ed Schein savaged the autocratic style of leadership in a recent interview. Typically, he articulates the downside of autocratic leaders far better than I ever could. “The basic principle is that learning only happens when survival anxiety is greater than learning anxiety. Of course, there are two ways to accomplish that. Either you can increase the survival anxiety by threatening people with loss of jobs or valued rewards, or you can decrease learning anxiety by creating a safer environment for unlearning and new learning. The problem is that the creation of psychological safety is usually very difficult.” (Source: Diane L. Coutu, Harvard Business Review)

So, as it turns out, we are back to the idea of safety again. If leaders are themselves demonstrably open to new learning opportunities, then they will reduce that learning anxiety, and make it safer for a team to experiment.

4. Courage to be wrong.

The idea of taking a failure bow in front of your team is that, when you make a mistake, you first draw attention to it, and then bow to your team, unashamedly accepting a round of applause from the room for acknowledging and learning from failure.

I first learned this protocol in a workshop with Deb Preuss and Lyssa Adkins, and it is a marvellous way to create a safe space in which a group can experiment, fail and learn together. I encourage you to experiment with failure bows with your team.

In ‘Being Wrong’, Kathryn Schulz analyses wrongness from two perspectives. First, how do we behave in that pit-of-the-stomach moment when we realise we are wrong? Do we double down and go for broke? Or do we work in the kind of environment where we can take a failure bow with our team, and learn from the wrongness together?

Schulz also deals with a rather weighty issue related to being right. Philosophers such as Karl Popper grappled with the idea of objective reality as far back as the 1600's, and how it was very difficult to ever be 100% confident of our own knowledge. In other words, we must be prepared that everything we say may in fact be ‘falsified’. Falsification is a philosophical approach to the accumulation of scientific knowledge, in that everything we know must be constantly refined. We are always learning new information. This means that we need to take our assumptions out for air every now and again and challenge them. The more often we do this, and the more we do it with out teams, the more we will learn and the the easier the process will become.

5. Courage to debate options

We value dialectic over dichotomy. In other words, we need courage to allow our own ideas to be falsifiable and also, to recognise and accept offers for collaboration from others. Don’t take positions, discuss alternatives!

We can learn from improvisational comedy (improv) here. In improv, the scenario is entirely new every time. Every line suggested by a player in the scene is therefore considered an ‘offer’. Players need to listen to the offers of their colleagues, process them quickly, and respond with a collaborative offer that builds something more. The parallels to collaboration are obvious.

When your team discuss ideas, do they build on each others’ offers? Or do they shut them down? A very effective way to close down an offer, and therefore stifle an attempt at collaboration and creativity, is to block it. In Improv, a block is a way to stop a scene in it’s tracks. For example, imagine a scene set in a greengrocers. Liam is the shopkeeper, and Ricky is arriving to complain.

Ricky: (pretending to open the shop door) “Drrrring. Hello?”

Liam: “We’re closed.”

Suddenly, there’s nowhere for this collaboration to go. All the potential of this idea is now dead. We need courage to find ways to build on the offers of our team mates, to suspend our judgement on whether they will work or not, and just explore possibilities for a moment.

6. Courage to have difficult conversations

Bob Galen is a constant source of inspiration to me. This post really changed my attitude to having difficult conversations at work.

As a Scrum Master, and therefore responsible for being a change agent, if I cannot muster the courage to have a difficult conversation when it is required, then I will be ignoring one of my main responsibilities. A signal of a safe environment is the ability to have these difficult conversations.

A brief word to acknowledge Kim Scott’s wonderful idea of Radical Candor. I will cover this topic in a future post on the value of respect.

7. Courage to keep on keeping on

Finally, we all need the courage to stay true to our own values, and this will make us more authentic as a person, as a communicator, and ultimately as a leader. We all crave authenticity, and everyone hates bullshit.

Avoid that feeling in your gut that tells you ‘nooo’ when you are doing something against your own values and beliefs. Acknowledge when you are wrong. Learn from it.

“Know thyself and to thine own self be true” (Spoken by Polonius from Hamlet by William Shakespeare)

Or if Shakespeare doesn’t do it for you:

“Be yourself, everyone else is already taken” (Oscar Wilde)

If you want to stand still, then there is some good news! You don’t need any courage for that whatsoever. Change requires courage. However, change also provides courage. Take a deep breath. Give it a try. And when you fail, learn from it. This, my friend is how we learn.

As Debra Searle said in her keynote at SGLON18, “if we always do what we’ve always done, then we’ll always get what we’ve always got.”

In closing, I hope that this post has covered some concrete ways to live the Scrum Value of courage, and that it has encouraged practices and behaviours that can you help you live it in your team.

Please consider this post my offer to you. Do you have any other practices to suggest in return? Let’s keep this list going!

Hope you enjoyed this post. Thanks for reading!

Do you want to write for Serious Scrum or seriously discuss Scrum?
Scrum
Organizational Culture
Values
Livingthescrumvalues
Serious Scrum
Recommended from ReadMedium